AWS Schema Conversion Toolを使ってNetezzaからRedshift用データをS3にエクスポートする

AWS Schema Conversion Toolを使ってNetezzaからRedshift用データをS3にエクスポートする

Clock Icon2017.05.16

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

最新のSCTでは、DWH のデータを Redshift用のデータファイルとして、エクスポートし、S3にアップロードする機能が追加されました。 本日は、Netezza のデータをエクスポートして Redshift にロードするまでをブログにて紹介します。

はじめに

AWS Schema Conversion Tool(以下、SCTと略す)は、データベースのスキーマを分析してRedshift のスキーマに変換・生成できるツールです。以前に Netezza から Redshift のスキーマに変換・生成する機能をブログにて紹介しました。

AWS Schema Conversion Toolを使ってNetezzaからRedshiftにスキーマ変換する

SCTのエクスポート機能を用いることで、移行元のデータベースのデータのエクスポートとS3へのアップロードを自動化します。S3にデータを置く場合の2つを考慮点である「データの分割」と「データの圧縮」も自動的に行われます。

AWS Schema Conversion Tool Exports Vertica, Greenplum and Netezza Data Warehouses to Amazon Redshift

システム構成 〜 エクスポートを担う Migration Agent

1台のSCTと複数のMigration Agentで構成されます。SCTは複数のMigration Agentに対してExportタスクの実行を指示します。指示されたMigration Agentはそれぞれデータベースに接続してローカルにダンプします。ローカルにダンプした後S3へ自動的にアップロードします。分割したデータファイル名を定義したマニフェストファイルが生成されて、S3上のバケットに保存されます。

migration-agents-art

引用:Using Data Extraction Agents より

新しく導入された『Migration Agent』を複数台配置することで水平スケールに対応します。

Migration Agent がサポートしているデータベース

Migration Agent がサポートしているデータベースは、以下のDWHのみです。つまり、DWHを移行するためのガチのツールです!

  • Greenplum Database (version 4.3 and later)
  • Microsoft SQL Server (version 2008 and later)
  • Netezza (version 7.2 and later)
  • Oracle (version 11 and later)
  • Teradata (version 14 and later)
  • Vertica (version 7.2.2 and later)

SCT と Migration Agent の導入

SCTの導入

SCT の導入とスキーマ移行については、以下のブログを御覧ください。

AWS Schema Conversion Toolを使ってNetezzaからRedshiftにスキーマ変換する

SCTのセキュリティ設定

SCT と Migration Agent間のSSLキーを設定します。[Global Settings]-[Security]タブを選択して、Trust Store と Key Stores を設定することができます。今回はこの画面で Trust Store と Key Stores を生成して設定しました。

20170509-sct-security-setting

Migration Agentの導入

次に Migration Agent を導入します。Migration AgentはJavaアプリケーション/JDBCなので、Java8を事前にインストールしておきました。 様々なOSに対応していますが、今回はWindows版のインストーラー(aws-schema-conversion-tool-extractor-1.0.601.msi)を導入しました。

20170509-migration-agent-install

Migration Agentと通信するためのサービスポートに「8888」、データベースに「Netezza」を設定します。

20170509-migration-agent-install-2

上の画面でSSLを有効に設定したので、SCTの[Security]タブ生成した Trust Store と Key Storeを指定します。

20170509-migration-agent-install-3

設定が終わったら、StartAgent.bat を起動します。

SCT に Migration Agent を登録

SCT に Migration Agentを登録します。[View]-[Data Migration View]を選択して、画面下の [Register] ボタンを押して、Agentの設定を入力します。ホスト名にAgentのIPアドレス、ポートにAgentのポートを指定します。SSLをチェックするとSCTに設定済みの Trust Store と Key Store が設定されます。

20170509-migration-agent-regist

登録が成功すると、以下のようにビューに追加されます。

20170509-migration-agent-management

データのエクスポート

データをエクスポートするには、左のナビゲーションから1つまたは複数のテーブルを選択して右クリックし、[Crete Local Task]を選択してTask名を指定すると [Task]タブに追加されます。

20170509-sct-create-local-task

Task名を選択して、下の[Start]ボタンを押すと直ちに実行します。Netezza から Migration Agent データを取得する「export_user(Local)」と取得したデータをS3にアップロードする「export_user(S3)」の2ステップで実行されます。

20170509-sct-run-task

マネジメントコンソールからバケットの内容を見ると、指定したバケットの下にハッシュのようなフォルダが作成され、データファイルとマニフェストファイルはその下にアップロードされていることが確認できます。

20170509-amc-sct-s3-2

S3 ファイルを Redshift にロード

このままではデータがどのフォルダに格納されているか容易に特定できません。以下の例では、データファイルのパスをデータファイルのプレフィックスから取得しています。

$ aws s3 ls s3://cm-bucket/ --recursive | grep cmdb_cmuser_users
2017-05-01 19:50:18        293 320361b15da94387bc15cdfcb866931f/0dc84192d06249198d5ace889feed05c/15e4d5339b424ae7bc78a1879236b666/unit_1/cmdb_cmuser_users_chunk_1.csv.lzo

S3のフルパスがわかったので実際にロードします。

cmdb=# COPY cmdb_cmuser.users
cmdb-# FROM 's3://cm-bucket/320361b15da94387bc15cdfcb866931f/0dc84192d06249198d5ace889feed05c/15e4d5339b424ae7bc78a1879236b666/unit_1/unit.manifest'
cmdb-# CREDENTIALS 'aws_access_key_id=<aws_access_key_id>;aws_secret_access_key=<aws_secret_access_key>
cmdb-# LZOP
cmdb-# DELIMITER '|'
cmdb-# REMOVEQUOTES
cmdb-# IGNOREHEADER AS 1
cmdb-# MANIFEST
cmdb-# COMPUPDATE OFF
cmdb-# ;
INFO:  Load into table 'users' completed, 1 record(s) loaded successfully.
COPY

DMSとSCTのS3エクスポート機能の使い分け

DMSでも同じようにソースデータベースにあるデータをS3に保存する機能が先日提供されました。SQL ServerにあるデータをS3に保存する機能については以下のブログを御覧ください。

DMSを使ってSQL ServerのデータをS3に出力する

では、似たような2つの方式はどのような違いがあるのでしょう?

DMSはAWSのVPC内からオンプレ環境のソースデータベース(DWHシステム)に対してJDBC接続してデータを取得、データをS3にアップロードします。長所はソースデータベース以外に用意しなければならない機器が特に不要です。短所はパブリックもしくは専用回線(Direct Connect)など、DMSからソースデータベースに接続できるネットワークが要件を満たしていなければなりません。

20170509-DMS-S3

一方、SCTのS3エクスポート機能はオンプレ環境のソースデータベース(DWHシステム)からデータを取得して圧縮、ソースデータベースのネットワークから圧縮したファイルをAWSのS3に直接アップロードします。短所はSchema Conversion ToolやMigration Agentを用意しなければなりません。長所はMigration AgentからS3へのアウトバウド接続になるので、ソースデータベースのネットワークに対して外部接続の許可やインバウンド設定等が不要になります。DWHシステムのネットワークにインバウンド接続しなくて済むのは安心です。

20170509-SCT-S3

まとめ

SCTによるデータのエクスポート機能は、ネットワークの制限が多い環境においても導入しやすく、データファイルをLZOPで圧縮して転送するのでネットワーク帯域も削減できるので、より実践的な機能といえます。

最新のリリース(1.0.602)では、エクスポートしたデータをターゲットデータベースであるRedshiftにロードできるようになりましたので、こちらにつきましては改めてブログで紹介したいと思います。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.